1. Field of the Invention
The present invention relates to a method and a network architecture for mapping Internetworking Protocol (IP) multicast and Integrated Services (i.e. differing levels of quality of service) over an Asynchronous Transfer Mode (ATM) network. The method and architecture, which are based upon multicast switches, allow IP/Resource. Reservation Protocol (RSVP) applications running on ATM hosts to seamlessly participate in Internet-wide multicast sessions. The method and architecture make good use of ATM capabilities to support features such as receiver heterogeneity, shortcut routing and scalability.
2. Description of the Related Art
The current Internet services, including IP multicast, are based on best effort delivery of datagrams as the sole underlying mechanism. The best effort delivery mechanism however, is not suitable for transporting media streams such as audio and video over the Internet, since applications using such streams often require data delivery with delay and bandwidth guarantees for a successful replay of media streams at the receiving end. Furthermore, Internet traffic continues to grow faster than the speed at which additional capacity is being added to the Internet infrastructure. This means that data traffic traversing the Internet is subject to unpredictable delays and possibly packet loss due to the increased load on Internet routers.
While traditional Internet applications such as email, file transfer, remote login etc., based on transmission control protocol (TCP), can adapt their network usage to the prevailing conditions, emerging multimedia applications, such as video on demand and those based on streaming video, are less tolerant to changes in traffic parameters such as end-to-end delay and jitter. The only way to support these multimedia applications (other than over engineering the Internet capacity) is to provide multiple service classes and a capability of reserving resources in the Internet.
As a result of the efforts of the Internet Engineering Task Force (IETF) (See, e.g., Wroclawski, Specification of the Controlled-Load Network Element Service, Network Working Group, Request for Comments: 2211, Category: Standards Track, September, 1997; and Shenker et al., Specification of Guaranteed Quality of Service, Network Working Group, Request for Comments: 2212, Category: Standards Track, September, 1997), support for Quality of Service (QoS) based service classes, known as Integrated Services, is expected to become available in the Internet in the near future. In addition, Resource Reservation Protocol (RSVP) is also being standardized by the IETF as an internetworking protocol for resource reservation that will be used by applications in the multi-service Internet. See, R. Braden, et al., xe2x80x9cResource Reservation Protocol (RSVP)xe2x80x94Version 1 Functional Specification,xe2x80x9d Internet Engineering Task Force, Network Working Group, Request for Comments: 2205, Category: Standards Track, September, 1997.
Asynchronous Transfer Mode (ATM) has been developed as an integrated link layer and network layer solution for providing QoS based services in local and wide area networks. Although the ATM technology supports its own version of QoS based services, it is unlikely that ATM networks will completely replace the existing IP based Internet infrastructure in the foreseeable future. Therefore, at least in the initial stages of ATM deployment, hosts connected to ATM networks will continue to run IP and RSVP applications in order to communicate with other hosts, most of which may still be connected to legacy networks, such as Ethernet.
Since the ATM technology readily provides the QoS support needed for IP Integrated Services, the problem of mapping these services over an ATM network appears to be simple. However, such a mapping is quite difficult due to the following reasons:
(1) Since IP is the network layer protocol of choice for use with RSVP, all the network technologies ranging from Ethernet to Token Ring to ATM will be treated as link layer technologies by RSVP/IP. Such an approach does not give rise to any conflicts with the use of conventional network technologies such as Ethernet, but with ATM networks this approach has an inherent problem in that it fails to make use of the network layer capabilities (addressing and routing) of ATM;
(2) IP multicasting, which is at the core of Integrated Services and RSVP, is being deployed widely in the existing IP networks. On the other hand, support for efficient multicasting in ATM is still inadequate. Point-to-multipoint virtual circuits (VCs), although supported in ATM, suffer from scalability problems; and
(3) Some of the RSVP features, namely receiver heterogeneity and dynamic QoS, do not have equivalent mechanisms in ATM.
One proposal to deal with the provision of IP Integrated Services over ATM is the Cell Switch Router (CSR) from Toshiba. See, Katsube, et al., xe2x80x9cToshiba""s Router Architecture Extensions for ATM: Overview,xe2x80x9d Network Working Group, Request for Comments: 2098, Category: Informational, February, 1997. A CSR is a traditional IP router attached to an ATM switch and is capable of xe2x80x9cconcatenatingxe2x80x9d incoming and outgoing VCs to provide shortcut paths through routers in an ATM cloud. Individual intra-logical IP subnet (LIS) VCs (host to router or router to router) are established using ATM signaling. Such VCs may be point to point for unicast, or point to multipoint for multicast. Different VCs may be established for different xe2x80x9cflowsxe2x80x9d between the same set of endpoints to allow for a different QoS for each flow, e.g. using RSVP. The problem is that CSRs use IP based protocols to route data traffic and thus limit the use of ATM protocols to intra-LIS routing. Some of the disadvantages of this approach are:
(1) A true shortcut path between two endpoints may not go through a router (CSR) which is given as the next hop by IP routing. This is because IP routing needs to send all data crossing subnet boundaries through a router (CSR);
(2) Wide area addressing and routing capabilities of ATM are not utilized properly by this approach since ATM is used only as a link layer; and
(3) Currently there is no proposal to handle heterogeneous QoS receivers in a multicast session with CSRs.
Two other recent proposals dealing with IP switching, are IPSILON and IPSOFACTO. See, A. Acharya, et al., xe2x80x9cIP switching over fast ATM cell transport (IPSOFACTO), Proc. Of IEEE Globecom ""97, 1997; and P. Newman, et. al., xe2x80x9cTransmission of Flow Labeled Ipv4 on ATM Data Links Ipsilon Version 1.0xe2x80x9d, Network Working Group, Request for Comments 1954, Category: Informational, May, 1996. IP switching xe2x80x9cidentifiesxe2x80x9d long lived IP flows passing through a switch router (IP switch) and places such flows on a fast switched path so that subsequent data packets on these flows do not incur reassembly, routing and segmentation delays at the router. IPSILON uses a heuristic based on the number of packets with the same source and destination addresses to identify a long lived flow. IPSOFACTO relies on the control packets of higher layer protocols, e.g. SYN packets in TCP, to identify long lived flows. Once a long lived flow is identified, it is assigned a new Virtual Circuit Indicator/Virtual Path Indicator (VCI/VPI) by the IP switch. At the same time, an association between the incoming VCI/VPI and outgoing VCI/VPI is established in the switching fabric so that subsequent data packets are forwarded without any intervention by the routing software. IPSILON relies on a proprietary protocol for assigning VCI/VPI to IP flows between two IP switches. IPSOFACTO uses a technique based on partitioning of VCI/VPI space and chooses an unused VCI/VPI from this space for forwarding a flow through each IP switch. The only difference between the two IP switching techniques and the CSR technique described earlier is the way shortcut VCs are established by the switch/router. Apart from this difference, the two IP switching techniques and CSR rely on IP routing software to make routing decisions. As such, all the drawbacks listed earlier for CSR, apply equally well to the two IP switching techniques.
Additionally, the IP over Non-broadcast Multiple Access (NBMA) networks (ION) working group of the IETF has developed a proposal for IP multicast over ATM which is based on Multicast Address Resolution Servers (MARSs) See G. J. Armitage, Support for multicast over UNI 3.0/3.1 based ATM networks, Network Working Group, Category: Standards Track, Request for Comments 2022, November 1996. An enhancement to the basic MARS approach is the concept of a Multicast Server (MCS). See R. Talpade, et al., Multicast server architectures for MARS-based ATM multicasting, Network Working Group, Category: Informational, Request for Comments 2149, May 1997, which helps aggregate traffic from multiple senders to a given multicast group. If one active MARS per LIS is used in an ATM cloud, point-to-multipoint VCs for multicast distribution are confined to LIS boundaries and inter LIS multicast forwarding is accomplished by multicast routers. Shortcut routing of multicast traffic is not possible in such a case. On the other hand, if one MARS is used for the whole ATM cloud, point-to-multipoint VCs may span the whole ATM cloud which causes scaling problems if the number of ATM hosts in the ATM cloud is large. See G. J. Armitage, VENUSxe2x80x94Very Extensive Non-Unicast Service, Internet Engineering Task Force, Network Working Group, Request for Comments: 2191, Category: Informational, September, 1997. As a comparison, the inventive network architecture, discussed in more detail below, is scalable since it uses separate VCs for intra and inter LIS multicast traffic, while allowing shortcut routing by concatenating these VCs at multicast switches (MSWs). Another problem with the MARS/MCS approach is the inability of multicast senders to communicate QoS requirements to the MCS for the multicast traffic originating from the sender. However, in the present invention, since the MSW is the termination point for RSVP messages within an LIS, using it as an MCS allows the use of QoS VCs from the sender to the MSW/MCS.
In yet another proposal, the Integrated Services over Specific Link Layers (ISSLL) working group of the IETF deals with the mapping of Integrated Services over ATM, treating it as a link layer technology. The current proposals in the ISSLL working group for mapping RSVP over ATM (see Crawley et al., A Framework for Integrated Services and RSVP over ATM, Internet Engineering Task Force, Internet Draft,  less than draft-ietf-issll-atm-framework-00.txt greater than , Jul. 24, 1997; and Berger, RSVP over ATM Implementation Requirements, Internet Draft,  less than draft-ietf-issll-atm-imp-req-00.txt greater than , Jul. 11, 1997), recommend supporting a modified homogeneous model as an approximation to full receiver heterogeneity. In the proposed scheme, all QoS receivers are served by a single QoS VC, and best effort receivers are served by a separate best effort VC if they cannot be served by the QoS VC. The ISSLL proposals contain no clear discussion of multicasting across LISs (i.e., inter-LIS multicasting). Although it allows the existence of a MARS and also some shortcut routing, it is not clear if a single point-to-multipoint VC per sender (or MCS) will span the ATM cloud connecting senders directly with receivers or if IP routers will be called in to route multicast traffic between LISs. A part of the confusion stems from the fact that the ISSLL group by definition is constrained to treat ATM as a link layer technology, although ATM can be utilized to perform routing functions as well. Shortcut routing, which allows multicast traffic to bypass multicast routers and requires a broader outlook, clearly falls outside the purview of the ISSLL working group.
Another recent proposal in the ISSLL group uses Next Hop Resolution Protocol (NHRP) to establish shortcut paths with QoS between two hosts/routers connected to an ATM network. See, Guerin et al., Support of Shortcuts for RSVP Flows Over ATM, Internet Engineering Task Force, Internet Draft  less than draft-guerin-issll-rsvp-shortcut-00.txt greater than . See also, Luciani et al., NBMA Next Hop Resolution Protocol (NHRP), Routing Over Large Clouds Working Group, Internet Draft  less than draft-ietf-rolc-nhrp-12.txt greater than . Although this proposal does establish a shortcut path between the two endpoints using ATM signaling, it does not handle the multicast case since NHRP cannot resolve multicast IP addresses to ATM addresses.
Another proposal discusses different alternatives for establishing RSVP reservations for unicast and multicast flows. Various methods are described to achieve both root-initiated (root of the multicast tree) and leaf-initiated (a leaf could be a multicast receiver or an egress router) shortcut paths through an ATM network. Birman, et al. xe2x80x9cProvisioning of RSVP-based services over a large ATM network,xe2x80x9d IBM Research Report (Computer Science) #RC 20250, October, 1995. However, all the methods described for establishing shortcut paths through the ATM network require modifications to RSVP processing at the routers. Furthermore, direct shortcuts from senders or ingress routers to receivers or egress routers do not scale if the number of multicast receivers is large. The aforementioned methods are described in a very general form and no concrete implementation details are mentioned. Additionally, there is no mention of how heterogeneous receivers can be supported. By contrast, the present invention, described below with reference to a preferred embodiment, implements a scalable network architecture based on multicast switches which provides shortcut paths that are incrementally established and concatenated for scalability. Support is also provided for heterogeneous receivers. No modifications are needed in RSVP processing. The aspects related to ATM and shortcut routing are handled only within multicast routing.
Another recent proposal describes the design and implementation of a switch router that is capable of providing quality of service using RSVP. E. Basturk et al., Design and implementation of QoS capable switch-router, Proc. of the Int""l Conference on Computer Communications and Networks (IC3N), Sept. 1997. Detailed design and implementation of the hardware in the switch router is presented. The switch router described can be thought of as a CSR from Toshiba (described earlier), augmented with QoS capabilities using RSVP. The proposed Switch-Router uses IP routing protocols and RSVP to establish unicast and multicast switched paths in an ATM network. The ATM network, as in Toshiba""s CSR, is treated as a layer 2 network so that forwarding across subnet boundaries takes place via a router (switch router in this case). However, the switch router architecture is described in isolation without any mention of how such switch routers will work together to provide a scalable mapping of IP multicast and RSVP over sizable ATM networks with features such as receiver heterogeneity. There fore, most of the limitations arising out of the use of IP based protocols in ATM networks as described earlier in the discussion on Toshiba""s CSR, apply to this switch router as well. In particular, the issues related to VC management for an ATM network consisting of a number of LISs and using the addressing and routing capabilities of ATM are not addressed in this paper. Furthermore, extensions to RSVP messages are required to carry VC information from one switch router to the other.
By contrast, the present invention describes a scalable network architecture based on multicast switches, which supports features such as shortcut paths and receiver heterogeneity. Details are provided below to show how multicast switches can operate together to provide IP multicast and Integrated Services in an ATM network, exploiting the routing and addressing capabilities of ATM as much as possible. Furthermore, no modifications are needed in RSVP messages in the inventive architecture.
The present invention provides a solution to the problem of supporting IP multicast and Integrated Services over ATM. The invention sets forth a method and network architecture, based on multicast switches for mapping IP multicast and Integrated Services over ATM networks. A multicast switch (MSW) is an ATM switch that can also perform the functions of an IP multicast router, including that of terminating RSVP messages. The primary problem addressed by the present invention is of mapping the protocol mechanisms (IP multicasting protocols and RSVP) that deliver IP multicast and Integrated Services to suitable mechanisms provided by ATM networks.
The present invention, in providing a solution for mapping IP multicast and Integrated Services over ATM, also provides a means for addressing the following objectives.
The first objective is to allow for receiver heterogeneity. RSVP allows different receivers in a multicast session to reserve resources with different QoS parameters. It is also possible that some receivers do not reserve any resources, but instead prefer to receive data with a best effort delivery mechanism. All such receivers must be supported by an RSVP over ATM mapping. Since a point-to-multipoint VC in ATM cannot have different QoS parameters associated with its different branches, supporting receiver heterogeneity may require multiple VCs with different QoS parameters.
The second objective is to provide for shortcut routing. Shortcut routing for unicast traffic in an ATM cloud helps eliminate intermediate routing steps by using the routing and addressing capabilities of ATM in case two communicating hosts are connected to the same ATM network. Using a mechanism like NHRP, a sender can find out the ATM address of the receiving host and establish a direct VC to it. Extending shortcut routing to multicast data traffic causes a variety of problems, however. First, using a shortcut point-to-multipoint VC for a multicast session in an ATM cloud will burden the sender with managing a VC that can potentially span multiple LISs and have a large number of recipients. Second, shortcut routing for multicast will allow data traffic to bypass multicast routers. This means that RSVP control messages (PATH and RESV) may follow a path that is different from the data path, giving rise to inconsistencies between the path characteristics computed by RSVP control messages and those actually encountered by the data traffic. A mapping must therefore clearly specify the manner of support for shortcut routing for multicast traffic.
The third objective is to provide adequate VC management. A mapping should specify how VCs are established for multicast data traffic and RSVP control traffic. This involves identification of the end points where a data or control VC terminates. This also involves delegation of VC management duties to senders and/or routers to handle changes in group membership. If a mapping supports direct point-to-multipoint VCs between a sender and all the receivers in an ATM cloud, the sender needs to manage the VC endpoints. When new receivers join the multicast session, they have to be added as leaf nodes to the point-to-multipoint VC. On the other hand, when existing receivers leave the multicast session, they have to be removed from the point-to-multipoint VC.
The fourth objective is to allow for dynamic QoS. RSVP allows multicast receivers to change their resource reservations at any time. Currently, User Network Interface (UNI) and Private Network Node Interface (PNNI) standards of the ATM Forum do not allow changing QoS parameters for an existing VC.
A fifth objective is to provide scalability. A mapping should be scalable to a large number of receivers and possibly a sizable number of senders as well. As noted above, direct point-to-multipoint VCs from a sender to all multicast receivers within an ATM cloud does not scale.
A sixth objective is to make efficient use of ATM capabilities. A mapping of IP multicast and RSVP over ATM should make use of ATM capabilities as much as possible even though some form of IP routing support will be required. A solution based purely on IP multicast routers is thus clearly undesirable.
A seventh objective is to provide interoperability. A mapping should ensure interoperability with Inter Domain Multicast Routing (IDMR) protocols that may be in use outside the ATM cloud. If the protocol used for multicasting within the ATM cloud is different from the one used outside the cloud, edge multicast switches should facilitate interoperation between the two. Support for native ATM applications should also be provided since it is very likely that host end systems connected to an ATM network will need native ATM access as well, in addition to an RSVP/IP interface.